Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closely Linked Artists + annotated reference lists #580

Merged
merged 16 commits into from
Nov 17, 2024
Merged

Conversation

towerofnix
Copy link
Member

@towerofnix towerofnix commented Nov 17, 2024

Adds a new field to groups, Closely Linked Artists, which shows at the top of the group's info page:

Xszelor's group info page, with a new paragraph reading: 'View artist page: Xszelor. (line break) View alias pages: Dvojka, Highblood, and Realmite.' The links are colored blue, instead of orange, differentiating from other generic links on this page.

A backlink to the group also shows on the corresponding artist pages:

Highblood's artist page. The short existing 'Notes' section is missing, and replaced by a short line linking to the group page: 'This artist is an alias of Xszelor.' Xszelor's artist page. The context notes still link to the usual pages, but there is also a line beneath linking to the group: 'This artist has a group page: Xszelor.'

Closely Linked Artists is an annotated reference list—a new basic data structure. The "alias" annotation gets a custom presentation, following along #550 and #568.

The implementation for annotated reference lists mostly stems from annotated artwork reference lists (no PR), which are now coded in terms annotated reference lists. This PR however introduces reverse annotated reference lists. It also factors out some code common in forward reference lists, and introduces related handy data utilities.

  • inputNotFoundMode: Now a utility function (ala inputWikiData), instead of hard-coded for each use.
  • raiseResolvedReferenceList: Now a composition of its own, factoring out behavior related to applying a specified notFoundMode. This is sufficiently generic for use in all forward reference lists (and similar data). It's also a bit nicer of an implementation compared to the existing code in withResolvedReferenceList.
    • Rather than check non-nullness of results itself, this takes a filter input, which (of course) may be computed separately from the results input where relevant.
  • performAvailabilityCheck: Now a standalone utility function. Only accessible as a helper in #composite/control-flow.
  • withAvailabilityFilter: New control-flow compositional step. This is just like withResultOfAvailabilityCheck (which underlies many control flow steps), but operates on a data list. It's typically more useful as a compositional step, combining nicely with withFilteredList and anything that takes a filter as an input—including raiseResolvedReferenceList.
  • referenceListInputDescriptions and referenceListUpdateDescription: Now utility functions, bundled together in a reference-list-helpers.js helper. These are closely related and responsible together for conveniently building the custom update descriptions that reference lists use.
    • These newly include support for providing multiple classes or reference types (as in mixed reference lists), and reflecting those in the update description.
    • These are relevant to reference list property compositions (#composite/wiki-properties), not withResolved... compositions (#composite/wiki-data).
  • annotatedReferenceList and withResolvedAnnotatedReferenceList: Like normal reference lists, but with an annotation property for each item. At the moment the reference itself is always specified in a reference property, and exposed (transformed) in thing.
    • Implementation derives from referencedArtworkList, which is now in terms of this, and still includes the relevant find.mixed / combineWikiDataArrays stuff.
  • reverseAnnotatedReferenceList and withReverseAnnotatedReferenceList: The usual. Spiritually these are similar to reverse contribution lists, because they're reversing based on a property, but they are also responsible for flipping the directionality of the reference: thing points forward in a forward list, backward in a reverse list.
    • We might change this to align with contribution lists, where every in-between node points in both directions and is identity/value-equal whether you found it forwards or backwards. For now we're letting these differently shaped data structures coexist, though.
  • withStretchedList: New generic data composition that underlies the flipping behavior in reverse annotated reference lists. It repeats each item in a list by a corresponding length.

@towerofnix towerofnix merged commit e6aa957 into preview Nov 17, 2024
@towerofnix towerofnix deleted the group-artists branch November 17, 2024 17:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant